[レポート]JAWS-UG 東京 #32 マイベストヒット 2019 #jawsug

こんにちは。岩城です。 2019/09/26（木）に開催されたJAWS-UG 東京 #32 - マイベストヒット2019に参加してきましたのでレポートします。

#レポート

#AWS

岩城匠朗

2019.09.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。岩城です。

JAWS-UG 東京 #32 - マイベストヒット 2019に参加してきましたのでレポートします。

概要

JAWS-UG東京 #32 は、2019年にリリースされた何かにDeep Diveしたら幸せだった、つまり、今すぐ試してみる価値が高いとユーザーの認める新機能に関する勉強会です。

Agenda

Timeline	Title	Speaker※敬称略
18:30 - 19:00	Registration & Social
19:00 - 19:05	会場説明	小深田あゆみ/田尻彩夏
19:05 - 19:20	AWS Client VPN を使ってみて最高なところ	菊池修治
19:20 - 19:45	COBOL on Lambda	岡智也
19:45 - 19:55	CloudWatch Anomaly でいろいろやってみた	山崎奈緒美
19:55 - 20:00	休憩
20:00 - 20:15	BCPについてみんなで考える	吉田真吾
20:15 - 20:35	Transit Gateway と Storage Gateway	小野雄太郎
20:35 - 20:40	僕の愛する AWS Amplify Console	清水勇大
20:40 - 20:45	AWS Global Accelerator を某ブログに導入してみた	鈴木亮
20:45 - 20:50	AWS Security Hub の話	山口正徳
20:50 - 20:55	Amazon Alexa の最新機能の話	田尻彩夏
20:55 - 21:00	AWS Cloud Map 本番運用の感想	小笠原寛明
21:00 -	撤収〜懇親会へー

場所

2019/09/26（木）18:30 〜 21:00
アマゾンウェブサービスジャパン株式会社
- 東京都品川区上大崎3-1-1 目黒セントラルスクエア 21F

セッション内容

セッション資料は、公開され次第記載していくつもりです。

AWS Client VPN を使ってみて最高なところ

発表者
- 菊池修治さん
発表内容はブログにてアップロードされています

JAWS-UG東京 #32 – マイベストヒット2019 で AWS Client VPN について話しました #jawsug

AWS Client VPNとは
- 昨年のre:Inventで発表
- 2019/5/20 東京リージョンで使えるようになった
Client VPNの作成
- クライアントIPV4 CIDR
  - 通信先ネットワークは重複してはいけない
  - ブロックサイズは /22〜/16の範囲
Client VPNのやってみたブログ4本ある
AWS Client VPNの特徴
- VPCを超えた先への通信が可能になったことが最大の特徴
Sito to Site VPNの場合
- 接続先のVPC内までしか通信できない
- 接続先のVPCからその先へホップする通信ができない
Client VPNの場合
- VPCピアリングの先のVPCに通信できる
そもそもなぜ、Site to Site VPNでは接続先のVPCを超えられないのか
- 端的に言うと仕様
- Site to Site VPN/Peeringのルートテーブル
  - VPC Routerが持つルートテーブル：任意編集
    - VGWとPCXそれぞれにルーティングできる
  - PCXのルートテーブル:Peeringにより自動設定
    - 繋がっているVPC間通信のルーティングだけ自動で設定され、任意編集できない
  - VGWのルートテーブル：BGP or Staticで設定
GWサービス(VGW/PCX/IGW)は直接つながる宛先しかルーティング不可能
Client VPNは？
- ENIが作成されVPC内のPrivateIPが割り当てられる
- Clientからの通信はENIのIPにSourceNATされVPC内リソースと同様に通信可能
ENIを持つClient VPNはVPC内リソースと同じ扱いなので通信可能
注意すべきこと
- VPN接続元が常にクライアント
- VPCからクライアント方向に通信することはできない

COBOL on Lambda

発表者
- 岡智也さん
- JAWS-UGでの登壇は初めて
- 2010年の第0回に貰った古いAWSのロゴステッカーをPC変わっても張り替えて使っている！
COBOL on Lambda
- 去年のre:InventのKeynoteで発表
- 突然のCOBOLで会場がざわついた
- Twitterもざわつく
  - トレンドワード1位
何が起こったのか
- COBOL on Lambdaは2つの機能により実現している
  - Lambda Layers
    - ファンクションの中で共通に使う機能をライブラリとして定義できる
  - Custom Runtime API
    - Lambda標準サポート外のプログラミング言語をファンクションで実行できる
- AWSのみで独自にサポートしたわけではない
  - Blu AgeとAWSの協業によりCustom Runtime APIを使ってCOBOLがサポートされた
  - Blue Age
    - フランスの会社
    - レガシーアプリケーションのクラウドネイティブ化（FaaS/CaaS）に積極的に取り組んでいる
COBOL on Lambdaソリューションの実行イメージ
- COBOLのソースコードをJarファイルにコンパイルし、JavaのLambdaファンクションとして実行される
- COBOL on Javaと思われるかも知れない
  - Blu Age提供の専用プラグインをVSCodeに追加
  - VSCode上でCOBOLソースコードを記述、コンパイルを実行
  - コンパイル用URLにアクセス、Jarファイルが生成され、ローカルにDLされる
  - 生成されたJarファイルを元に作成時にBlue Age提供のLambda Layers ARNを指定
  - イベントをトリガーにファンクションを実行
  - ファンクション実行時にBlue Age提供のLambda Layersの共通機能が利用される
COBOL on Lambdaソリューションのデモ
- COBOL GitHubで検索するとサンプルが色々公開されている
- BluAge/ServerlessCOBOLforAWS
Why COBOL?
- COBOLで開発されたメインフレームの基幹系システムが現在も多数存在する
- 2025年までに現行の基幹系システムで利用されているハードウェアやソフトウェアの保守期限切れを迎える
- COBOLを保守できるエンジニアが引退してしまう
- COBOLで実現されている業務トランザクションをいかにデジタルトランスフォーメーションするかが喫緊の経営課題
- それの一つの取り組みがCOBOL on Lambda
アプリケーション・モダナイゼーションのアプローチ例
- メインフレーム
  - 基本的に新規投資が少なく、運用保守が80%くらい
- オープンシステム（ステップ１）
  - オープンシステムに持っていき、新規投資の枠を増やす
- 次世代システム（ステップ２）
  - 最適化（リファクタリング）
  - イベント・ドリブンで動かせる箇所があれば、ServerLessを採用することでコストメリットが出てくるケースも
  - Blue AgeのFaaS/CaaSソリューションは、ステップ2においてクラウドの強みを生かすことができるクラウドネイティブなアプローチ
まとめ
- COBOLのソースコードをjarにコンパイルし
- Lambdaソリューションはその一部
- アクセンチュアはCOBOLを解析して新しい言語に置き換える部署がある
- Goで基幹系システムを開発している部署もある

CloudWatch Anomaly でいろいろやってみた

発表者
- 山崎奈緒美さん
監視のしきい値設定って難しい
- CPU90%超えていてもシステムが安定してれば良いのでは？
- どういうしきい値が良い？
CloudWatch異常検出
- 機械学習アルゴリズムを適用
- 通常と違う動きがあったら検出する
CloudWatch Anomalyを作成
- CloudWatchメトリクスを選ぶ
- 統計種別を選ぶ
- 折れ線をクリック
- 少し待っていると出来上がる
- アラームも作成可能
- 超簡単
ALB別、TG別メトリクスでやってみた
- Target Response Time
- Request Count
  - 自社サイトがTVで紹介されていて普段とは違う時間帯にアノマリーを検知できた
- HTTPCode_Target_5XX_Count
活躍しそうなメトリクス
- レイテンシー系
  - ELB
  - APIGateway
  - etc
- スループット・トラフィック系
  - DX
  - CloudFront
  - EC2
  - EFS
    - PercentIOLimit
    - リミット超過すると動きが遅くなるので監視する
- 使用率系
  - CPU
    - AutoScalingではCPU使用率超過時の通知は不要で、後から追えるようにしたら良い
  - Disk
  - DBコネクション数
  - T2/T3インスタイプのバーストクレジットのバランス
監視に困ったら
- AWSにおけるモニタリング議論のための観点総ざらえ

BCPについてみんなで考える

発表者
- 吉田真吾さん
- AWS DEVELOPER INFLUENCER SUMMITにて優勝
- すごい
  - Twitchチャレンジで優勝した
- 優勝の打ち上げの裏で日本が大変なことになっていた..
東京リージョンで発生したEC2とEBSの障害
- いまや多くの社会インフラの基盤であることが分かった
事業継続計画(BCP)が必要
ワークショップ
- Multi-AZにしたら良いの？
- サーバーレスなら万能なの？
- マルチクラウドにしたら良いの？
- ミッションクリティカルはオールインできないの？
- オンプレも持っておいた方が良いの？
- （システム）アプリケーションのポータビリティは確保しておくべき？
- ※ワークショップ内容はSNS投稿禁止でしたので記載しません
サイダスの場合
- 今回の対応から学んだこと
  - 素早さのためには「組織的な」準備が必要
  - 想定外は重なることがある
- 今回の対応の後に変えたこと
  - 重要業務の特定
  - 統括ルーム組成の自動化（責任者、SRE、カスタマーサクセス）→対応開始を早く
  - 定期的な全社BCP訓練→定型的な対応を素早く確実に
  - SREの教育、成熟化→クラウドの中身まで想像してトラブルシューティングできるレベル
- 今回の対応の後で変えなかったこと
  - AWS(東京) with Multi-AZ
SORACOM
- 復旧時間39分
- すごい
  - Connectivity issue for SORACOM IoT SIM (for Japan) plan-K
サーバーレスは銀の弾丸か？
- No
- 「実行環境の都度確保」「自動リトライ」などの特徴によるロバスト性の高さ
  - ロバスト：堅牢性
- オペレーションが必要なポイントがほとんどクラウドベンダー側になるため、復旧対応の労力・リードタイムが極小化可能
- サーバーレス固有のコンポーネントに障害が発生ないとは限らない
  - サーバレス化を推進する価値は期待できる
serverless/DAYS 2019に参加を!
- https://tokyo.serverlessdays.io/

Transit Gateway と Storage Gateway

発表者
- 小野雄太郎さん
Gateway
- ネットワーク屋さんがゲートウェイと聞くとワクワクするよね
- Storage Gateway
- Transit Gateway
S3を他でアクセス可能にするGateway
- ファイルゲートウェイ
  - SMB or NFSの共有をS3に同期する
  - オンプレで同期され、非同期でS3に同期される
- ボリュームゲートウェイ
  - ISCSIターゲットになれるゲートウェイ
    - キャッシュ型と保管型
- テープゲートウェイ
  - 仮想テープ装置として見える
ファイルゲートウェイを紹介
- VPC上にも作れる
  - オンプレミスに置くと思われがち
  - エンドポイントが必要
    - Storage Gatewayエンドポイント
    - S3エンドポイント
    - STSエンドポイント
  - 通信に必要となるポートが多いのでSecurity Groupでの許可も漏らさずに行う
- ファイルを共有する
  - 予めADドメインに追加
    - DCの名前解決などは別途環境を整えておく
  - ドメインユーザを使わない場合
    - ゲストパスワードを設定する
  - 共有を読み書き可能or読み取り専用にできる
  - 共有の設定を閉じないと先に進めないのがハマリポイント
- こんな使い方がある
  - 既存システムとの連携に超便利
    - 既存データをAWS上へ簡単に送りたい
      - S3にinternet経由
      - VPCにプロキシを立ててS3 VPCエンドポイント経由
      - SCPクライアント入れる
    - AWS上で処理した結果を社内に戻したい
      - マネジメントコンソールから
      - CLIをバッチファイルに組み込む
      - SCPクライアント
  - オンプレのデータをS3経由で活用
    - オンプレのサービスやクライアントPCからファイルゲートウェイ経由でS3へデータ追加
    - S3へ追加されたデータをLambdaなりで取り込んで使っていく
  - クラウドの出力オンプレミスへ
    - クラウド上で生成されたアウトプットを既存システムやクライアントで利用
    - 読み取り専用ファイル共有を使い、S3内のデータをそのままオンプレミス側に公開
- たとえば
  - データ分析プラットフォームの出力
    - エンドユーザにマネコン触らせたくない
    - SCPでも良いけど..
  - 読み取り専用のファイル共有
    - ADと連携しているため、新規ユーザが追加となっても追加作業不要なのは良い
- S3に直接追加されたファイルが共有に出てこない
  - S3のデータを直接編集するのは推奨されない
  - ファイル共有が読み取り専用なら、キャッシュ同期するだけで不整合は気にせず大丈夫なはず
- 読み書き可能な共有で、IAMロールにS3の書き込み権限がないと不整合出るから注意
Transit Gateway
- 複数のVPCをつなぐGateway
- Transit Gatewayを使うことで、複数VPC同士、複数VPCとDXを接続できる
Direct ConnectのTransit Gatewayサポートが東京リージョンに対応
- 祭りだ！
- AWS Direct Connect support for AWS Transit Gateway is Now Available in Six Additional Regions
- DXとTGWはASが異なる必要性があるので注意
  - 恐らくDXからは別のASをルーティングしているのかも

僕の愛した AWS Amplify Console

発表者
- 清水勇大さん
- 沖縄在住、東京出張中
うまくいかなかったことを発表
こんな課題を解決する
- プロトタイプを作ってユーザ検証をしたい
ここでいうプロトタイプとは
- モックアプリではなく
- データの流れが見えるもの
そこでAmplify
- フロントエンド＆バックエンド一緒にデプロイ！開発に集中できる
フルスタック！サーバレス！
- GitHub にpush
- Amplify
  - 勝手にデプロイしてくれる
- Amplify CLIでバックエンド構築
- ローカルからDynamoDBまで疎通確認できる
- Amplify Consoleの設定はらくちん
  - GitHubのリポジトリを選択
  - Buildの設定ファイルは自動で作成される
  - デプロイの状況を確認可能
- コンソールからアプリにアクセスすると、なぜかCognitoが必要な旨のエラーが出力
  - ローカルだとうまくいくのに
  - Amplifyからはうまくいかない
- なぜCognitoが必要なのか教えてほしい！

AWS Global Accelerator を某ブログに導入してみた

発表者
- 鈴木亮さん
Global Accelerator
問題（制約）
- ソースIPの変換
  - GAでNATされたIP
  - アップデートによりALBだけは対応
- CWのメトリクス
  - GAのメトリクス提供なし
- フローログ解析
  - フローログ設定とAthena解析系が必要
- タグ未対応
  - リソース名でやりくり、コスト分類タグが使えない
- Alias未対応
- コスト
  - 国内であれば10%増し
  - 海外との通信だと2割〜4割増し
まとめ
- Global AcceleratorはCDN
- リージョン間DRにも今後使えるかも
  - Auroraのリージョン間レプリケーションが東京でサポートされれば、マルチリージョンにも対応できそう
- Developers.IO 2019で発表します

【11/1（金）東京】国内最大規模の技術フェス！Developers.IO 2019 東京開催！AWS、機械学習、サーバーレス、SaaSからマネジメントまで50を越えるセッション数！

AWS Cloud Map 本番運用の感想

発表者
- 小笠原寛明さん
導入したアーキテクチャ
- Fargateでホスト、ECSのマイクロサービスアーキテクチャ
- Cloud Mapで内部通信
Cloud Mapとは
- ECSのサービスディスカバリを含む、AWSリソース検出の仕組み
  - プライベートなドメインの登録・更新
- ここでサービスの利用状況を参加者に質問
  - ECSを利用している人、会場の2割くらい
  - ECS間の繋ぎこみをALBで行っている人、上記2割のうち数人程度
本番導入の感想
- 導入が楽
- 裏側で勝手にできちゃう
- CFnやTerraformで管理している人はどんなリソースが裏で作成されるか確認すること
- 導入後の運用で活用
  - LBとECSサービスの疎通失敗の調査で便利
  - あるサービスのドメインが環境ごとに変わったりしない
  - 疎通確認しやくすくなった
気になっていること
- サービスの属性やARNの解決など、使っている人の話を聞きたい
  - 会場内には使っている人はいない
まとめ
- CloudMapを使うとFargateに内部からアクセスしやすくなる

AWS Security Hub の話

発表者
- 山口正徳さん
Security Hub
- 2019/6/24 東京でも提供開始
セキュリティ利子区対応
- 低減
- 保有
- 回避
- 移転
開発環境
- プロジェクトの立ち上げと新規構築の頻度がほぼ同一
- 開発環境だから本番環境よりもセキュアでなくても良いということでは許されない
- 開発速度、スケジジュールも重要
- チーム、ロケーションにより環境に対する制約も変わる
- ベースライン、ルール、教育はあるもののすべてのエンジニアがAWSプロフェッショナルではない
  - Permissions Boundaryも使っている
- 回避できずに低減、享受などの対応を選択する必要がある
感想
- アラートの正規化が不要
- カスタムアクション
  - SSHフルオープンになっていることを検知し、SecurityGroupを外すことができる（要Lambda)
- 頑張ってほしいこと
  - カスタムアクションの自動実行ができない
  - CIS AWS Foundation以外の対応
  - Insightでパイチャートなど他のグラフ病への対応
  - Control Towerとの連携

Amazon Alexa の最新機能の話

発表者
- 田尻彩夏さん
スキル内課金
- 5/31から日本でもスキル内課金が可能に
課金の種類
- 買い切り
- サブスクリプション
- 消費型
- ガチャ的なものも作れる
- 既にある
  - アタック25
Alexa スキルビルダー
- 8/6から日本語で受験可能に
- スキルを開発するのに必要な知識が出題される
- Lambda、DynamoDB、どういうふうに会話を作るかも出題される
Alexa-hostedスキル
- Alexaがホストとなる
- Developers Consoleにコードを書くだけでスキルを作成できる
- pythonも使用可能に（今まではNode.jsのみ）
New デバイス
- 9/25 Amazon devices Eventで新しいデバイスが発表された
- echo buds
  - AirPodsみたいなやつ、気になる
- echo frames
- echo loop
- でも日本での発売予定なし
まとめ
- Alexaでお金稼げる
- スキルビルダーが日本語受験可能
- 日本でもっとデバイス発売してほしい

おわりに

多岐に渡るサービスについて、各人の背景を交えながらの発表を聞けてとても有意義な時間でした。

ちょうど案件でVPCピアリング経由のオンプレへの通信をできないことの技術的な根拠を調べる機会があり、とても役に立ちました。 COBOL on Lambdaでは、なんでCOBOL？という思いが先行していましたが、よく考えれば基幹系システムで未だに保守され続けていて、 EOSLを迎えるためにデジタルトランスフォメーションが不可欠で一部利用できるケースがあるかも知れないことは納得でした。 BCPについて考えるでは、ワークショップという形で実際に障害対応にあたられた方の話を直接聞けて面白かったです。 AWS認定資格11種コンプリート目指しているのでAlexaスキルビルダー頑張ります。

本エントリがどなたかのお役に立てれば幸いです。